What Makes A PM A Great PM

Before going any further into this post, I should preface this by saying that anything and everything below is purely my subjective view on what makes a Program Manager a great Program Manager. I consider myself lucky enough to have experienced what it’s like to be a PM on a product team, and currently - on a content team, and this blog post is a reflection of my experiences across the two completely different organizations.

If you are not yet aware of the history of the PM role at Microsoft, I highly recommend you start with this post by Steven Sinofsky. Just like Steven, a couple of years ago I made the transition from SDE to PM and it has proven to be an enlightening journey.

First and foremost, a great PM has a 360 degree view on the product they are working on. Granted, when you start, you might think - “But I am working on a single feature, so I will focus on that.” Yes and no. At the end of the day, you are working on a piece of a larger product puzzle, and your puzzle piece needs to fit perfectly within the broader context. Which means that you need to be aware of what your product mission is, what critical parts make up that mission and who drives those. It’s surprisingly easy to silo yourself - don’t do it. There is no longer such a thing as “I don’t work on that piece” - you might not be working on it, but you can be sure that no feature is there on its own.

When you just start in your career, or transition into the PM role (maybe it’s the same team, or a different team) - establish a close relationship with both the engineering and management counterparts on the horizontal product space. Just like I mentioned in my post about my PM internship at Microsoft, it is key that you reach out and learn, learn and learn again about the product that you’re working on, especially a product that has been on the market for an extended period of time. Who are your users? What are their habits? What are the top issues across? It’s eye-opening to realize just how much of an impact you are delivering with a seemingly fenced-off component.

Another trait that I consider a great PM to carry is the ability to apply soft skills. Without going in depth as to what soft skills represent (you can read more on the Wikipedia page), it is critically important to develop communication skills, capacity to work well with a team, show confidence, patience, presentation skills and most importantly - customer empathy. A Program Manager is often the face of the work being done by many people - the way you represent yourself is the way you represent your product. In addition to that, your product serves the purpose of delivering value to end-users, so you absolutely must have a tight connection with those who are actually leveraging the work done by your team.

Let’s also talk about the ability to be a jack-of-all-trades to some extent. This might vary between teams, organizations and even companies, but I strongly believe that a great Program Manager should be able to quickly learn and switch context when needed. From my own experience, there were times when I needed to write a spec, but there are also times when I needed to write code and build tools for the team to use (such as Hummingbird). A great Program Manager does not shy away from things that are not 100% declared in the role. Yes, of course - among other things, you will need to make sure that you prioritize and balance responsibilities to have maximum positive impact on the product and the company, but often that involves thinking outside the box of the what a stereotypical Program Manager would do (if there is even such a thing).

The interesting factoid here is that the whole PM role was created because engineers were spread too thin and there were a plethora of product-related tasks that they simply did not have hours in the day to tackle. To reference Steve’s post from above:

Program managers got started at Microsoft while developing Excel for the Macintosh. The challenge the company saw was that we were stretched thin trying to push the state of the art in technology (in this case develop for a brand new OS using brand new Graphical User Interface concepts) and so the developers were very busy just trying to make things like printing, display, graphics, etc. work as well as trying to develop new algorithms for spreadsheets and modeling.

So by nature, a PM is responsible to both look at the horse race, analyze it, and make sure that his horse (in this case - the product) has the best qualities to win throughout its lifetime. In order to be able to do that, a great PM has the duty to be able to quickly assess different aspects of the process and make adjustments where necessary. This is even more important today than 10 years ago, when a misstep in product development or planning will cost millions in addition to time wasted on things that resulted in nothing.

A great Program Manager is not there for the sake of the hierarchy, but rather to drive the larger vision of the product. Around the same time last year, Zach Watson published an article called “Are Project Managers Irrelevant” (and yes, in this case I am fully aware that Project Manager != Program Manager), that brought up this point:

It’s also becoming clear that Millennials, who will make up the majority of the workforce in the coming decades, don’t appreciate hierarchy simply for hierarchy’s sake. Their continual access to technology has engendered an intrinsic need for meritocracy – simply because someone has a higher title doesn’t mean Millennials will assume they have infallible expertise.

The example above states that a Project Manager is placed in a team to be some kind of a superior employee that will rule everything under. That is not the case with PMs that are fully immersed in the product as well as culture of the company where their team has many interdependent links that aren’t necessarily stacked on top of each other. It is unreasonable to expect an engineer to be there to conduct user studies, drive research requirements, analyze product sentiment, analyze incoming telemetry and many other responsibilities on top of actually building the product. The same article subsequently goes into the following area:

In this sense, project managers are no longer fulfilling their role as facilitators, but are instead broken cogs in the processes of innovation and productivity. In an era where agility is treated with the same kind of reference as innovation, having team members that actually stifle speed could be considered unforgivable.

Having Program (or Project) Managers that are not facilitators is an organizational, and not a role, problem. You want facilitators in your organization - this is where rigorous interview and post-interview work comes into play. Fully understand - a Program Manager is not there to track the time and micromanage every single aspect of the product, quite the opposite - PMs should be able to rely on their engineering team to realize 100% of their potential in the product, while making sure that they apply that potential on the right things.

For an interesting perspective, a Harvard Business Review article details how in 2002, Google decided to flatten their organization:

Since the early days of Google, people throughout the company have questioned the value of managers. That skepticism stems from a highly technocratic culture. As one software engineer, Eric Flatt, puts it, “We are a company built by engineers for engineers.” And most engineers, not just those at Google, want to spend their time designing and debugging, not communicating with bosses or supervising other workers’ progress. In their hearts they’ve long believed that management is more destructive than beneficial, a distraction from “real work” and tangible, goal-directed tasks.

A few years into the company’s life, founders Larry Page and Sergey Brin actually wondered whether Google needed any managers at all. In 2002 they experimented with a completely flat organization, eliminating engineering managers in an effort to break down barriers to rapid idea development and to replicate the collegial environment they’d enjoyed in graduate school. That experiment lasted only a few months: They relented when too many people went directly to Page with questions about expense reports, interpersonal conflicts, and other nitty-gritty issues. And as the company grew, the founders soon realized that managers contributed in many other, important ways—for instance, by communicating strategy, helping employees prioritize projects, facilitating collaboration, supporting career development, and ensuring that processes and systems aligned with company goals.

No matter what product is being developed, there are more faces to it than engineering. And this is where the truly great PMs shine. The reality is quite simple - a PM is, by default, given plenty of flexibility and at the same time - accountability, to define the role for himself or herself.

Great PMs are made - nobody I know came in on day one and just started being the best - there is a learning curve, but that curve can be drastically leveled the moment you start channeling into the right aspects of the job. This will help you in the long run as a PM that is both valued by the team and is enjoying the ride.

And last but not least, a great PM finds a way to deliver. Bottom line is - it does not matter how many emails you sent, how many meetings you scheduled or how many people you talked to if the deliverables are not there. In this case, you should be aware of your surroundings and plan accordingly - who do you need to contact, when do you need to get some additional help and when do you need to pull the plug on a feature or component?

With everything stated above, I attempted to keep it very short and focus on the key aspects that I noticed helped me a lot through the past year and a half. In a year, I would love to come back to this post and revise it with other additional learnings.